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“A couple drops of blood is all that is needed to diagnose a patient’s health 
or disease” is a frequently used headline describing the aspirations for 
many new diagnostic tools in which both simple collection of small speci- 
men volumes and rapid turn-around-time of test results aim to increase 
patient compliance and accuracy of treatment. The physician office is often 
the target market in higher-income countries and private healthcare sys- 
tems, with recent interest in moving these capabilities closer to the patient 
in retail settings such as the corner pharmacy. The global health community 
is another target for these technologies; a healthcare setting is often depicted 
with images of a minimally trained community health worker who travels 
extreme distances, solely equipped with a backpack full of drugs and tests 
administered “under a tree.” 

Developing diagnostic tools that meet the needs of these settings—a 
physician office, a pharmacy, and a backpack—seems simple enough. Yet, 
the fast pace of diagnostics-focused innovations in microfluidics, signal 
transduction, and multiplexing is faced with an asymmetric adoption rate in 
any of these settings. Beyond the simplest format, the lateral flow rapid diag- 
nostic test (RDT), and complex cartridges that operate on laboratory-based 
instruments such as Cepheid’s GeneXpert system, there is a paucity of other 
microfluidic formats that have been implemented at significant scale. 
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As discussed in this chapter, the commercialization and adoption bottle- 
necks for these moderately complex diagnostics cannot be overcome by 
technological innovation alone, particularly in the highly regulated and 
payer-limited healthcare and public health markets. Diagnostics, unlike 
other clinical products, is not an intervention but a decision-aid that guides 
the use (or nonuse) of an intervention. It is important that the value proposi- 
tion for any technology-centric innovation in diagnostics include a strong 
link to a gained efficiency in making a specific decision. Any assay devel- 
oped without context to the system, users, decision points, and downstream 
interventions resembles one that is more targeted to the research community, 
rather than clinical care or public health. 

This chapter highlights considerations for designing a diagnostic for use on 
individual patients or populations by assessing and incorporating the answers 
to two fundamental questions—who is asking for the test and how do test 
results guide a decision—questions that cannot be addressed in isolation of the 
user community. The methodology described is a best-practice for assessing 
and ensuring that user needs are central to the design, development, and eval- 
uation of a new diagnostic tool. The assessment starts with a clear intended- 
use statement that is centered around an actionable decision and justifies the 
time and cost to obtain a diagnosis. This definition is used to frame use-cases 
and user scenarios that identify users and describe how the test will be imple- 
mented, as well as criteria for generating an actionable test result. All three of 
these assessments are then used to create a list of product attributes that are 
required to meet the needs of an end user. The diagnostic developer plays a 
convening or observer role in the market assessment up until this point but has 
an active role in defining the technical performance specifications for a prod- 
uct that can satisfy the criteria described in these requirements. This process 
may be laborious, but centering design principles and functionality around 
user-needs avoids the creation of a proverbial hammer looking for that nail. 


9.1 Defining How the Test Guides a Clinical or 
Public Health Decision: Intended-Use 


Oftentimes, the value proposition for a new testis described through improve- 
ments in physical operability, speed, and ease of use, with little details on 
how test results improve a clinical or public health decision. Designing a new 
diagnostic should always start and remain accountable to a clearly defined 
“intended-use” that is grounded by the utility of the test's results, framed by 
an agreed-upon decision algorithm that links a patient encounter with a deci- 
sion to prescribe or not prescribe a specific intervention (see Box 9.1). 
Clinical utility includes circumstance, decision, and action: definitions that 
justify the use of a test, presentation of test results to a user (e.g., qualitative, 
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BOX9.1 DIAGNOSTIC ALGORITHMS 


The absence of a decision tree or algorithm is a good indicator that the 
tool is more appropriate for research use instead of the clinical market. It 
is important to remember that diagnostic tools are used to guide a deci- 
sion for individual clinical care or population-based public health. For 
instance, a diagnostic intended for measuring disease prognosis often 
results in a decision to monitor individuals more or less frequently with 
another test, depending on the interpretation test results in context of 
predetermined risk criteria. Similarly, results from a diagnostic used to 
measure the presence of an infection guide decisions on the course of 
intervention—using these types of diagnostics without access to treat- 
ment options could be considered unethical. Public health diagnostics 
could be used to monitor the resurgence of a previously quenched 
disease within a given population; positive results might be weighed 
with other considerations, such as population mobility, to guide a deci- 
sion to test each individual with a more specific (and oftentimes more 
expensive) secondary diagnostic. 

These decision trees are often published by a group of disease spe- 
cialists convened by an overarching organization. Most global health 
communities, reference guidelines, recommendations, and policies 
are provided by global or regional departments of the World Health 
Organization (WHO) and/or by the ministries of health at the country 
or subnational levels. The algorithms integrate all healthcare tools— 
diagnostics and treatment—relying on evidence that assures safety and 
effectiveness for each recommended decision. Health economics also 
plays a large part in the rationale for these algorithms in which cost- 
effectiveness includes the resources required to perform the test, test 
performance, and availability of tools for intervention, considerations 
that are important for the resource-constrained global health market. 


semiquantitative, and quantitative), and types of measurements needed to 
produce interpretable test results. Defining the patient's situation provides 
criteria that justifies a decision-maker to administer the test such as presenta- 
tion of symptoms, ongoing treatment (such as a companion diagnostic), or 
other risk-associated factors such as geography, environment, or disposition. 
The action could be prescription or modification of a therapy, additional test- 
ing (such as subtyping or confirmatory testing), increased frequency of test- 
ing, or a public health action such as quarantine, vector control measure, or 
mass drug administration. 

These attributes—clinical utility, presentation of test results, and interpre- 
tation to inform a specific decision—form the two to three sentences that 
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comprise an intended-use statement. This statement should match an exist- 
ing clinical or public health practice, not a hypothetical or aspirational work- 
flow, as these also describe the targeted commercial market and regulatory 
pathway. Itis an uphill battle if a developer envisions that a new technology 
will change guidelines and workflows because of placement of a new tech- 
nology in a clinical care or public health program. 

In addition to identifying the market, the intended-use statement is cen- 
tral to the design, development, and evaluation of a diagnostic by separat- 
ing “nice-to-have” technical attributes from “must haves.” The latter are the 
bare minimum requirements to successfully meet the needs of an end user 
in which every claim in the intended-use statement needs to be validated 
with clinical evidence. One should be critical of these intended-use claims, 
remembering that analytical validation studies are much simpler to perform 
and demonstrate compared to clinical validation studies. For example, if 
quantitative test results are essential for guiding a decision, studies can dem- 
onstrate analytical feasibility using spiked or contrived specimens. However, 
clinical feasibility must be demonstrated using nonaltered specimen from 
patient populations representative of the actual intended use, with statis- 
tically structured studies that evaluate the ability of the test to reproduc- 
ibly provide quantitative results relevant to the decision. Challenges could 
include access to specimens annotated with this level of quantitative data as 
well as lack of a quantitative gold standard comparator, and it is important 
to assess the availability of these resources during the planning process of the 
project. Alternatively, the bar for validating a test’s ability to reliably provide 
a qualitative “yes/no” result may be easier to cross, particularly if this type 
of test result is all that is needed to guide a specific decision; in this example, 
quantitation may be a “nice-to-have” that does not impact the final decision. 


9.2 Defining How a Test Will Be Used: Use-Cases 


The intended-use statement is a generalizable description that is enriched 
with use-cases and user-scenarios to add context to the decision algorithm. 
The goal of this exercise is to systematically identify how a test will be imple- 
mented and used, details that define requirements for getting a test used suc- 
cessfully. By weaving together details that identify users, workflows, and the 
settings in which the test is performed, the use-case and scenarios detail the 
“needs” that a test should address from the perspective of the user(s) within 
a defined healthcare system or public health program. 

It is important to note that each use-case does not equate to a single indepen- 
dent test; one diagnostic tool can solve the needs of many use-cases. However, 
a test developer should demonstrate feasibility against one use-case and then 
consider expanding to other use-cases. It would be detrimental to develop a 
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diagnostic that is not accountable to an intended use and associated use-case, 
or resource-intensive to simultaneously address multiple use-cases. 

As mentioned earlier, a use-case is not developed by a test developer as 
these descriptions are inherently technology agnostic and should be devel- 
oped by a community of end users to reflect current clinical or public health 
practice. At a high level, use-cases include details specific to the targeted 
patient population, decision-maker (user), healthcare or public health sys- 
tem, and linkage between the specific decision and interpretation of test 
results. 

Use-cases always start with identifying the patient population targeted by 
the diagnostic and expand on the short description used in the intended- 
use statement. These include patient characteristics that trigger the use of a 
test by a decision-maker, such as symptoms, ongoing treatment, associated 
risk factors, etc. Additional details include potential coinfections or other fac- 
tors that define eligibility or ineligibility for a test such as behavior, lifestyle, 
geography, environmental exposure, etc. 

It is also important to understand the patient situation. For example, 
some patients and their families might have made substantial effort to seek 
healthcare and thus may resist the concept that a test will determine if they 
receive treatment, particularly if the testing adds out-of-pocket cost or time. 
It is also important to understand the role of culture for a specific patient 
population—a positive test result may result in stigma or isolation, rather 
than seeking care. If properly identified, many of these risks can be mitigated 
in the design or implementation of a test. For instance, there may be differ- 
ent ease-of-use considerations if a tribal healer is more effective at obtaining 
patient compliance for testing compared to a healthcare worker. It may also 
be important that testing staff include resources for proper counseling if a 
patient will be informed about their test results. 

Another component of the use-case is the identity of the user, the indi- 
vidual responsible for making the clinical or public health decision with 
authority and resources to act on the test results, in accordance to a decision 
algorithm. By identifying the user, one can also deduce their workload. For 
instance, a clinician with a significant patient load might prefer prescribing 
treatment rather than waiting for test results. The user should not be con- 
fused with the test operator who performs the test, a role that is defined in 
the user scenarios. 

These details include circumstances for “why” the user seeks the test 
results, “what” decisions are made by the user, and “how” test results guide 
their decision. In many public health programs, the user may be a program 
manager who is only interested in aggregated diagnostic results of a pop- 
ulation, whereas a clinician or healthcare worker may be interested in the 
test results of an individual patient. Details may also include incentives or 
challenges for administering the test, such as cost or program achievements. 
Designing a test that addresses the pressures, incentives, and circumstance of 
the user are important not only for adoption by a healthcare or public health 
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system, but also routine use. Table 9.1 lists some assumptions about the user 
that should be defined in a use-case. 

Use-cases also include how the test will be interpreted, framing the criteria 
for making the results meaningful to the decision faced by the user. These 
details provide context to the decision algorithm by describing the type of 
analysis (e.g., organisms/molecules) and measurement parameters neces- 
sary for making a decision (e.g., level of quantitation). Natural history of 
disease can also be included if aspects such as stage or progression of disease 
are essential considerations for making a decision. This component of the 
use-case should also include integration with other data sources if the deci- 
sion requires consideration of nondiagnostic data. 

Severity of risk to a patient's health from an inaccurate result or diagnosis 
should also be elucidated, as related to the unintended misuse of an inter- 
vention. Defining the implications of an inaccurate result to a patient's health 
sets the threshold for allowable false positive or negative results, which are 
statistically inevitable but can be mitigated through the use of controls, pro- 
cesses, and other design criteria. 

Details about the healthcare system or public health program frame the 
resources available for administering the test and the prioritization of a spe- 
cific test in competition with other strategic priorities. It also describes insti- 
tutional buy-in for using a test, availability and adherence to guidelines or 
recommendations (see Box 9.1), infrastructure for both administration and 
sustainable operation of the test, identity of a payer for the test results, and 


TABLE 9.1 
Assumptions That Need to Be Evaluated 


Patient Stigma of diagnosis by social circles (family, friends, 
community) 

Methods for seeking care (traditional healers, spiritual, 
clinical) 

e Cultural /spiritual beliefs with collecting specimens 
Privacy considerations for non-blood-based specimens 
(urine, stool, genital swabs) 


Community healthcare worker e Confidence in operating new technology 
e Vulnerability to robbery /theft with more valuable 
technology 
Off-label use of technology 
Incentives 
Proficiency testing 
Turnover and training 
Decision maker e Patient load 
e Incorporation of test into clinical standard-of-care 
workflow 
Demographics of patients 
Incentives 
Off-label use of technology 
Proficiency testing 
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the regulatory pathway required for implementation. For instance, a pub- 
lic health program focused on a specific global health disease may dedicate 
resources (infrastructure, labor, funding, supply chain) into a specific testing 
program and also require that the test is evaluated through the World Health 
Organization's (WHO) prequalification program! to ensure that the test is 
manufactured using quality assurance processes and appropriate for use in 
the global health setting. Conversely, a primary healthcare system may have 
to balance their services among several disease priorities and may not be able 
to adequately resource or incentivize the use of a test. These components of 
the use-case can help forecast and mitigate several potential implementa- 
tion challenges. Using these examples, a multipathogen platform may be the 
advantageous route for implementing a diagnostic in the primary health- 
care setting but not practical for a disease-focused public health program. 
Common assumptions that many test developers take are listed in Table 9.2. 


TABLE 9.2 

Assumptions about the Healthcare System That Need to Be Evaluated 

Lack of testing is due to lack of e Identify who recommends the testing of a patient 
access / availability of an easily population. Design the performance and usability of 
performed test. a test around a treatment or decision algorithm, 


which often describes settings for the testing and are 
described in policy or guidelines authored by a 
country's Ministry of Health, or at a higher level by 
the World Health Organization. 

Identify who pays for the test, these usually fall 
under the auspices of a country's Ministry of Finance 
or nongovernment procurers such as The Global 
Fund to fight AIDS, tuberculosis, and malaria. 


Lack of testing is due to high costs Cost of goods should reflect costs and ability to 

of existing test. manufacture a design-locked device at scale, not 
costs reflecting construction of alpha-prototype. 
Costs should not be limited to the test /device by 
itself, but should include all costs to perform the 
test. In many instances, costs for training, 
proficiency testing, and infrastructure to implement 
a new test may outweigh its technological benefits. 
Components with low cost of goods may not be able 
to be manufactured at scale or under quality 
assurance requirements for in vitro diagnostics. 


Regulatory approval is simpler for Diagnostics that guide the clinical course for an 
global health diagnostics because individual patient often require the evaluation by a 
of the unmet need. stringent regulatory body and /or prequalification 

by the World Health Organization. 

Diagnostics that guide public health programs often 

follow recommendations, guidelines, or policies at 

the country level, or by the appropriate department 
of the World Health Organization. 
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The details described in this chapter only scratch the surface for develop- 
ing use-cases, and additional considerations relevant to the implementation 
of a specific test should be documented as part of the market assessment. As 
decision-aids, diagnostic tools are an essential part of a healthcare or public 
health system, and it is important to do these assessments and unpack a list 
of requirements for integrating a new test into these systems as part of the 
planning process. 


9.3 Defining Where a Test Will Be Used: User-Scenarios 


A use-case should be further enriched with the depiction of a user-scenario, 
a series of storyboards that describe “how” a test will be implemented and 
performed. These storyboards describe the resources needed to perform the 
test successfully by generalizing the testing workflow. Often a use-case is 
accompanied by several scenarios, a selection of which represent current 
practice and others that may require slight changes to the current workflow 
as necessary compromises for implementing a “better” test. It may be pos- 
sible to adjust the workflow in small pilot studies, but use of the test broadly 
and at significant scale requires that the test developer engage the related 
guideline and payer communities early in the planning process. 

This exercise may also reveal that scenarios are dependent on the healthcare 
systems within a specific geography. By defining as many scenarios as pos- 
sible, a test developer is given the choice to determine those that align with 
their business strategy and customize the design of the test around the circum- 
stances of the physical operating environment. As with the use-cases, a test 
that can be used in all scenarios is likely one that is not perfect for any of them. 

At a high level, user scenarios include: 


e Patient flow: Mechanism of patient encounter, number of patients 
seen over a set period of time (hours /days), and workload (patients 
arrive at one time or over a period of time). These considerations are 
used to define throughput for the test, batching requirements, and 
turnaround time for test results. For example, a patient seeking care in 
a dedicated facility complicates predictions on total throughput, mak- 
ing random access more amenable to this scenario. Conversely, if the 
patient encounter is through a door-to-door public health campaign, 
total batch size and turnaround times are dependent on coverage and 
defined logistics, making these requirements more predictable. 


e Testing environment: Examples include testing at the point of 
contact, transporting a medium-throughput mobile laboratory in 
proximity to a patient population (e.g., via a van), or collecting the 
specimens with shipment to a semi/centralized laboratory. These 
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considerations are used to define the operational conditions and 
environments to frame the physical format, availability of resources 
(running water, electricity, etc.), turnaround time, and accessories 
necessary for performing the test. 


e Staffing: Linked to the patient flow and workflow, this accounts for 
all individuals who interact with the patient—from preparation of 
the patient, collection and processing of the specimen, and operating 
the test. If applicable, it should also identify who provides counsel 
to the patient on their test results. The education and proficiency for 
performing these duties should be described as all of these consid- 
erations guide ease-of-use and training requirements. These details 
also inform throughput, batching requirements, turnaround time, 
and presentation of test results. 


e Location of decision-maker (user): Describes whether the decision 
is made at the same location of the test or if interpretation is made 
remotely. These considerations are used to define turnaround time 
and presentation of test results, and data-transmission requirements. 
For example, a rapid result may not be necessary if, for logistical or 
cost reasons, the interpretation and intervention options are located 
in a different location than the test. 


e Specimen custody: Details whether the specimen is acquired in 
a patient’s home, in the same location as the test, or is collected 
remotely and transported to a central laboratory. These details 
inform the need for additional consumables, such as specimen col- 
lection and preservation accessories, and define logistics require- 
ments for batching, shipping, and receiving specimens for testing. 


e Test deployment: Resources that a program or healthcare system 
dedicates to train and prepare test operators and users, assurances 
for steady supply chain of reagents and equipment maintenance, 
and infrastructure for transporting test equipment not used in a cen- 
tral location. These details could include procurers, storage, customs 
regulations, and transportation requirements. 


9.4 Translating Intended-Use, Use-Cases, and 
Scenarios into Product Requirements 


The last phase of the user assessment is the development of product require- 
ments. This is one of the hardest exercises as it involves compromise between 
“must have” requirements with “nice to have” attributes. The “must have” 
product requirements are the minimal criteria to meet end-user needs. 
They also set the bar for the performance of the test, as the final developed 
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prototype must meet all minimum requirements. As with the intended-use, 
use-cases, and user-scenarios, the product requirements should be defined in 
collaboration with the end user and technology agnostic. 

Compromises are inevitable in the creation of product requirements as they 
take into context end-user constraints or technical feasibility. For instance, 
in the global health setting, WHO has defined that the ideal test follows 
ASSURED criteria (affordable, sensitive, specific, user-friendly, robust and 
rapid, equipment-free, and deliverable to those who need them).? Each of 
those criteria have dependencies on each other. For instance, a highly sensi- 
tive and specific test may not be affordable or equipment-free, and it is up to 
the user-community to prioritize these attributes and define them as part of 
the product requirements. 

Product requirements are meant to evolve over time, and it is important to 
assess any impact of changes to the user scenarios, use-cases, and intended 
use. It is important to document any change to the original product require- 
ments by their causes and downstream implications to user acceptance. 


9.5 Translating Product Requirements into 
Technical Performance Specifications 


The product requirements set the goal for any new test, and it is now the 
responsibility of the developer to create the performance specifications that 
are achievable using their own technical approaches. This is the step where 
multiplexing, signal transduction, fluid manipulation, etc., can be incorpo- 
rated as long as these components improve the ability to meet the product 
requirements. As mentioned earlier, it may be possible that the original prod- 
uct requirements are difficult to meet with a technical solution, and itis up to 
the developers to engage the end users to identify implications for compro- 
mising these requirements. 


9.6 Concluding Thoughts 


Starting with the end in mind, where end user needs are central to design 
and development of novel products are the best practices for most sectors 
outside of biomedicine. As described throughout this chapter, user needs for 
diagnostics is multifactorial because of the dependencies on both the spe- 
cific decision and intervention, infrastructure required for implementing the 
test, and constraints from the regulatory and payer pathways. However, it 
is important to define criteria for a successful test before designing a new 
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diagnostic from the onset because the opposite approach of forcing a technol- 
ogy into the complexities of a healthcare or public health system without this 
context will likely fail to have meaningful impact. 
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